应用场景
异步处理：当用户注册成功后，需要发送注册成功邮件、新用户积分、优惠券等；缓存过期时，先返回过期数据，然后异步更新缓存，异步写日志等。通过异步处理，可以提升主流程响应速度，而非主流程或非重要处理可以集中处理
系统解耦：当用户成功支付完成订单后，需要通知生产配货系统，发票系统、库存系统、推荐系统、搜索系统等进行业务处理，而未来需要支持哪些业务是不知道的，并且这些业务不需要实时处理、不需要强一致，只需要报账最终一致性即可
数据同步：如果想把MySQL变更的数据同步到redis，或者将MySQL的数据同步到Mongodb,或者让机房之间的数据同步，或者主从数据同步等，此时可以考虑databus、canal、otter等。使用数据总线队列进行数据同步的好处是可以保障数据修改的有序性
流量削峰：系统瓶颈一般在数据库上，比如扣减库存、下单等。此时可以考虑使用队列将变更请求暂时放入队列，通过缓存+队列的暂存的方式将数据库流量削峰。同样对于秒杀系统，下单服务会是该系统的瓶颈，此时可以使用队列进行排队和限流，从而保护下单服务
缓冲队列
在电商进行大促时，系统的流量会高于平常流量的几倍甚至几十倍，此时应进行一些特殊的设计来保证系统平稳度过这段时期，而解决手段很多，一般牺牲业务的强一致性，来保证最终一致性即可。使用缓冲队列应对突发流量时，虽然不能使处理速度变快，但是可以使处理速度变平滑，从而不会因为瞬间压力太大而压垮应用。同时通过缓冲区队列实现批量处理、异步处理和平滑流量
任务队列
使用任务队列可以将一些不需要与主线程同步执行的任务扔到任务队列进行异步处理。比如线程池任务队列和Disruptor任务队列（RingBuffer）,如用户注册完成后，将发送邮件、送积分、送优惠券任务扔到任务队列进行异步处理；刷数据时，将任务扔到队列异步处理，处理成功后再异步通知用户。以及查询聚合时，将多个可并行处理的任务扔到队列中，然后等待最慢的一个任务返回
消息队列
使用消息队列存储各业务数据，其他系统根据需要订阅即可。最常见的订阅模式是：点对点（一个消息只有一个消费者）、发布订阅（一个消息可以有多个消费者）。而常用的是发布订阅模式
比如，修改商品数据、变更订单状态时，都应该将变更信息发送到消息队列，如果其他系统有需要，则直接订阅该消息队列即可
请求队列
请求队列是指类似在Web环境下对用户请求排队，从而进行一些特殊控制，流量控制、请求分级、请求隔离。例如将请求按照功能划分到不同的队列，从而使用不同的队列出现问题后相互不影响。还可以对请求进行分级，一些重要的请求可以优先处理。另外，服务器处理能力有限，在接近服务器瓶颈时需要考虑限流、最简单的限流就是丢弃处理不了的请求，此时可以使用队列进行流量控制
数据总线队列
一般消息队列中的消息都是业务维度的简单数据，如业务键或业务状态，在商品信息变更场景中，当SKU信息变更了，只下发一个SKU ID,订阅者需要再查一遍商品系统来获取最新的变更数据，进行商品信息缓存同步。所以使用现有的消息队列方式很难只进行变更部分的推送并保证数据的有序性。而此种场景比较适合使用数据总线队列实现，例如数据库变更后需要同步数据到缓存，或者需要将一个机房的数据同步到另一个机房，只是数据维度的同步，此时应该使用数据总线队列，如果阿里的Canal、linkedIn的Databus。使用数据总线队列的好处是，可以保证数据的有序性。阿里的otter是基于Canal的一款分布式数据库同步系统，如果想实时进行多机房、多数据库数据增量同步，则可以使用otter。如果需要全量离线数据增量同步，则可以使用kettle。